Subject: AppnTimeStamp and related changes

From: "David D. Chen ((919)-254-6182 8-444)" <[email-masked]>
Date: Fri, 10 Nov 95 11:55:40 EST

Ref:  Your note of 9 November 1995, 13:29:27 EST (attached)

I read both Bob Moore's and Jim Cobban's proposal.
I think it is good to introduce a structure like what
was proposed.  I have a few suggestions:

(1) Sound like xxxxNodeStartTime is equal to 0 or not is used
    as the indication of either the value of xxxxNodeUpTime,
    or the value of sysUpTime is used for those XxxxTimeStamp
    objects, respectively.

    I think it is fine as long as there is no case that
    xxxxNodeStartTime is equal to 0 and sysUpTime is used.
    The fact should be clearly stated in the Textual
    Convention.

    (or else, we can use COMPLIANCE to make one of the
    two not-accessible, and the other read-only).

(2) I think the Textual Convention of XxxxxTimeStamp
    should just state the fact of how the value should
    be interpreted.  All the statement about which timeStamp
    is preferred should be removed, since it is pure
    a product decision and only affect the functionality
    of the box.

    Instead, I suggest to have a paragraph in the front text
    section to describe the behavior of choices (again not the
    preference).

(3) The syntax of TimeInterval (INTEGER (0..2147483647))
    TimeTicks ([APPLICATION 3] IMPLICIT INTEGER (0..4294967295))
    is different.  I think the correct syntax for
    appnNodeUpTime should be TimeTicks.  Thus, the most
    dummy manager can display the variable based on the
    BER encoding and showed it in time format (instead of
    hundredths of seconds.)

David Chen

R.E. (Robert) Moore said:

... lines deleted ...

>
>
>
>-- *********************************************************************
>-- Textual Conventions
>-- ---------------------------------------------------------------------
>AppnTimeStamp ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>         "A time stamp indicating when an event occurred.
>
>         All events in this MIB are time stamped relative to a single
>         reference event.  If possible, an implementation should use
>         the same reference event it uses for sysUpTime, so that
>         the value of an object of type AppnTimeStamp will be the value
>         of sysUpTime at the time the event occurred.
>
>         An alternative is for an implementation to use as the reference
>         event the time at which the APPN node last came up.  In this
>         case a Management Station can relate APPN's time stamps to
>         sysUpTime by retrieving sysUpTime and appnNodeUpTime, which
>         indicates the amount of time that the APPN node has been up,
>         calculating the difference between them, and adding this offset
>         to the value of the AppnTimeStamp object.
>
>         The object appnNodeStartTime assists a Management Station in
>         determining how an agent is doing its APPN time stamping:
>
>             - If appnNodeStartTime + appnNodeUpTime = sysUpTime
>               at some point in time, then all objects of type
>               AppnTimeStamp return the value of sysUpTime.
>
>             - If appnNodeStartTime = 0, then all objects of type
>               AppnTimeStamp contain time stamps offset from
>               sysUpTime by the amount sysUpTime - appnNodeUpTime."
>
>     SYNTAX  TimeTicks
>
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>appnNodeUpTime  OBJECT-TYPE
>      SYNTAX TimeInterval       -- from SMI-TC
>      MAX-ACCESS read-only
>      STATUS current
>      DESCRIPTION
>          "Amount of time (in hundredths of a second) since the
>          APPN node was last re-initialized."
>
>      ::=  { appnGeneralInfoAndCaps 6 }
>
>appnNodeStartTime  OBJECT-TYPE
>      SYNTAX AppnTimeStamp
>      MAX-ACCESS read-only
>      STATUS current
>      DESCRIPTION
>          "The time when the APPN node was last re-initialized,
>          measured in hundredths of a second."
>
>      ::=  { appnGeneralInfoAndCaps 6 }
>
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>appnLsMaxDelayTime  OBJECT-TYPE
>      SYNTAX AppnTimeStamp
>      MAX-ACCESS read-only
>      STATUS current
>      DESCRIPTION
>           "The time when the longest delay occurred, measured in
>           hundredths of a second.  This time can be used to identify
>           when this high water mark occurred in relation to other
>           events in the agent, such as the last time the APPN node
>           was re-initialized."
>
>      ::=  { appnLsEntry 37 }
>

---

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 10 Nov 1995 16:36:00 -0500

In message "AppnTimeStamp and related changes", 

>    The fact should be clearly stated in the Textual

     I was thinking we should define xxxStartTime as the value of
     xxxUpTime at the time the component last became active.  This
     is sort of implied by the syntax.
>    a product decision and only affect the functionality

     I am totally opposed to this.  It MUST be a preference to use
     sysUpTime for all services.  

      1) because EVERY other component of the system uses sysUpTime
      2) because it simplifies the job of the management system in
	 correlating multiple events which are related.

     I still have not seen any justification for using anything other than
     sysUpTime which compensates in any way for the problems which are
     caused when you decide to go your own way.  I will not accept any 
     solution which implies that an alternate time stamp is anything other
     than a kluge to get around a poorly designed implementation.

---

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 10 Nov 1995 10:55:00 -0500

I agree to this proposal, although I still do not believe that SNA MIBs
should ask for special treatment in the SNMP world unless it is absolutely
necessary.  SNA has enough antipathy to deal with without being saddled with
this.